Especially “else”, “elseif” and “switch” are most likely all over your codebase. Often we make code harder to read or even difficult to understand. And don’t get me started on testing, we cause this thing called Cyclomatic Complexity, and I’ve been told that’s bad. Our Speaker Sebastian Feldmann will show you some elegant and effective ways to get rid of us and make your code more comprehensible and easier to test. In the interview he answers some questions about this exciting topic.
Are switch statements really that much more simple than using if/else if/else structure?
Sebastian Feldmann: Switch statements are most of the time equally bad as if/else statements. Sometimes the one is more readable then the other, but both are conditionals, and conditionals often have the tendency to get messy. So no, switch statements aren’t any better then if else statements.
What options would I have except “else if” and / or “switch”, or where exactly is the difference between the two queries?
Sebastian Feldmann: Some developers are looking at me funny when I challenge them to implement a feature without using any conditionals. It’s good to remember that there are programming languages out there that do not even have an if-construct. There are a couple of things that you can use instead of conditionals, you can adopt concepts of functional programming for example. And off course there are design patterns helping you to reach a less conditional code base. The important thing here is „less“, then to get rid of all conditionals is not the goal here. The goal would be to identify conditionals that could make „problems“ in the future and to provide some guidelines how to deal with conditionals that got out of hand.
What is meant by cyclomatic complexity?
Sebastian Feldmann: Cyclomatic complexity is defined as “the number of linearly independent paths in a program” and yes, that sounds highly academical. So let’s have a look at an example. If you have a function that doesn’t contain any conditionals, it is just command, after command and finally a return statement. This function has a cyclomatic complexity of 1. There is only one path thru this function. To test such a function you have to write one unit test. Let’s say we put one if conditional in this function. Now we have 2 execution paths. One where the if statement is fulfilled and executed, and the second one where it is not. To make sure both those cases work correctly you have to write 2 unit tests.
And now imagine the if condition contains an „or“ operator. Suddenly you have to write a third unit test, because you should test both if execution paths. The one where the if is executed because of the first part of the condition and one for the or part.
So long story short: Cyclomatic complexity is a software metric to describe the level of complexity in your software and tells you how many unit tests you should write to best test your software.
In your session, you’ll show some elegant and effective ways to make the code more understandable and easier to test. Can you give an example?
Sebastian Feldmann: Sure, or not so sure, let me think of something that is good to understand without looking at actual code. Imagine you wrote your own shop system and you have to handle different shipping options. Those have to be handled in a lot of places. The user can select them and maybe prices have to be recalculated. You maybe have to send out different tracking links to the customer and so on. Imagine doing this with if/else or switch everywhere. If you add a new shipping option you have to change a lot of code in a lot of places. By using shipping domain models you would get rid of all those conditionals and would improve your system immensely. But there are much smaller examples for instance getting rid of foreach loops with functional approaches like map, reduce and filter.
